第5章 具現化させる
プロジェクトのなぜか理解できたので、本章ではどうやって行うかを深掘りしていく。以下のインセプションデッキが対象
技術的な解決案を描く
リスクを検討する
プロジェクトの期間を見極める
諦めるべきものをはっきりさせる（何かを諦めるのは世の常だ）
プロジェクトに何がどれだけ必要なのかをスポンサーに提示する
5.1 解決案を描く
開発チームが解決案を考慮するときには図を使って議論すること。以下のようなメリットがある
ツールや技術に抱く期待をマネジメントできる
そう知恵しているプロジェクトの境界とスコープを目でみて確認できる
リスクを伝えられる
具体的なやり方は以下
どのようなシステムを構築しようとしているかを図にかく
どこにリスクがあるのかを銘各区にする
解決案に全員が同意できるか
5.2 夜も眠れなくなるような問題はなんだろう？
マネージャーがプロジェクトの状況が気になって夜も眠れなくなる原因は、プロジェクトにリスクについて議論していないから
リスクを話し合うことはいいこと
次の内容で当てはまる内容があればプロジェクトはうまくいかない
チームが同じ仕事場にいない
顧客を巻き込めない
自分の開発環境をコントロールできない
プロジェクト成功させるために必要だと思うものが揃っていない
プロジェクトのリスクを把握するメリット
課題を早い段階で把握できる
相手の意見に反対できるチャンスがある。違和感を解消することができる。
不安な気持ちを共有することですっきりする。チームの結束を高めるきっかけいにもなる
チームにとって取り組む値打ちのあるリスクを見極める
チーム全体でブレーンストーミングを実施して、「取り組む値打ちのあるリスク」と「取り組む値打ちのないリスク」に分類する
取り組む値打ちのあるリスク：プロジェクトでコントロールできるリスクについて見極め、対策を取り組む
Ex: 低スペックな開発マシン、人材が辞めてしまうかもしれない
取り組む値打ちのないリスク：コントロールできないリスクは何も対応しない
Ex: 不景気、会社の買収など
5.3 期間を見極める
小さく考える
ランディ・モット曰く、開発サイクルは最大でも六ヶ月まで。それ以上長くなると、要望が積み重なって肥大化していく 見積もる時には小さく見積もり、期間は六ヶ月以内が望ましい
プロジェクトの長さへの期待をマネジメントする
ステークホルダーに見積もりを報告をする時には、プロジェクトが期間内の終わりそうかといった未通しを報告する
提案するときには二つの選択肢がある
期日をゴールとして、見積もりを提案
メインの機能リリースすることにフォーカスして、ざっくりした見積もりを提案
5.4 何をあきらめのかをはっきりさせる
プルジェクトには無視できない影響力を及ぼす力（フォース）が存在し、厳守しすぎると他の要素がおざなりになり、トレードオフになる
フォースに４つある。時間・予算・品質・スコープ。
時間：お客さんの価値をあたえるのはリリースすること。これを優先的に考え、時間を固定にする。
予算：追加予算をお願いすることを避けるために、予算も固定にする
品質：高い水準を維持することは忘れていけない。品質も固定にする
スコープ：時間・予算・品質を固定にしたので、スコープは調整しスケジュールを調整する。（アジャイルサムライの教え）
トレードオフ・スライダー
スコープ・予算・時間・品質をメモリのイラストで管理して、チーム全体で認識を合わせておく
https://scrapbox.io/files/67f55c05b9b0257845fbc455.png
スコープに関してはお客様に合意をとる必要がある
全ての要素でマックスのメモリになることはNG
同じメモリの要素が二つ以上あってはいけない（優先順位をつけるため）
４つのフォースに意外にも「捉えどころのないもの」も考慮する
Ex: 思わずはまっちゃうぐらい楽しいコンピューターゲーム、コールセンターへの問い合わせを20%減、顧客で自分で問題を解決できる
5.5 何がどれだけ必要か
今までの内容を総括すると、次のようなチーム編成ができるはず。自分が必要と思うチームで編成すればいい
https://scrapbox.io/files/67f55fea7bb13b992f53db1c.png
アジャイル開発において顧客は役割を把握していない。そのため、顧客に確認しておく
プロジェクトのためにお時間をきちんと割けれるか
必要な決定をくだせるだけの権限は与えられているか
プロジェクトの方向性を決める役割であるということ認識しているか
最終判断を下すのは誰かを確認しておく
チーム方向性やタスクなどを決める時に、だれの意見を採用したらいいのかということが起きる。そのことを想定して、採取決定権がある顧客を確認しておく
これはステークホルダーが発言してはいけないということではなくて、開発チームに落とし込む時には一つにするべきという意味
コストは単純にステークホルダーの人数✖️期間✖️月単価の掛け算にする。一番コストがかかるのは人件費
最後のスライド仕上げる
顧客が求めているのは以下の二つなので、これをスライドにまとめる
いつ完了するのか
いくらかかるのか
現段階でのスライドはざっくりレベルになってしまう。これは仕方ない。
スライドは以下のイメージ、作り方はしっかりと練って承認してくれるスライドを作る必要がある
https://scrapbox.io/files/67f565872279537c61fa9b6f.png